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Abstract 

In the theory of programming languages, type inference is the process 
of inferring the type of an expression automatically, often making use 
of information from the context in which the expression appears. Such 
mechanisms turn out to be extremely useful in the practice of interac- 
tive theorem proving, whereby users interact with a computational proof 
assistant to construct formal axiomatic derivations of mathematical the- 
orems. This article explains some of the mechanisms for type inference 
used by the Mathematical Components project, which is working towards 
a verification of the Feit-Thompson theorem. 

1 Introduction 

Consider the following mathematical assertions: 

• For every x in R, = YlTLo fr- 

• If G and H are groups, / is a homomorphism from G to H, and a and b 
are in G, then f{ab) = f{a)f{b). 

• If is a field of nonzero characteristic p, and a and b are in F, then 

p 



ia + b)P = J2(^)'^'bP-' =aP 



There is nothing unusual about these statements, but, on reflection, one notices 
that substantial background knowledge and assumptions are needed to parse 
them correctly. For example, in the first statement, we take it that the index 
of the summation i ranges over natural numbers, or, equivalently, nonnegative 
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integers. Hence i\ is also an integer. Since x is explicitly flagged as a real 
number, the expression /il involves division of two different types of objects, 
taking into account that any integer can be viewed as a real number. In the 
second statement, G and H are groups, which is to say, each is a set of elements 
equipped with a group operation and an identity element; so when we write that 
a and b are in G, we really mean that a and b are elements of the underlying set. 
The notation ab denotes multiplication in G, while the notation f{a)f{b) can 
only be understood in terms of the multiplication in H. In the third statement, 
p is a nonnegative integer (in fact, a prime number, since nonzero field charac- 
teristics are prime). But unlike the summation symbol in the first statement, 
here the summation symbol refers to addition in F. In the third statement, (^) 
is an integer, while a* and are elements of the field. How do we interpret 
multiplication in that case? One way is to notice that there is a canonical map 
from the integers to any ring with a and a 1. Alternatively, any abelian group 
can be viewed as a Z-module, which means that it supports scalar multiplication 
by integers, with all the expected properties; and the additive part of a ring is 
an abelian group. 

Inferences like these are used not only to parse basic mathematical expres- 
sions, but also to reason about them correctly. For example, some "multipli- 
cations" and "additions" are commutative, and multiplication often distributes 
over the corresponding addition. Common manipulations with summations de- 
pend on such facts. Understanding mathematics presupposes the ability to keep 
track of the various domains that objects belong to and variables range over, 
as well as the relevant operations on those domains and their properties. Our 
faculties for doing this are so ingrained that we are scarcely aware of the back- 
ground knowledge we bring to the table when we read an ordinary mathematical 
text. 

The problem is that such background knowledge has to be brought to the 
foreground when it comes to formalizing mathematics. Broadly speaking, formal 
verification is the practice of using formal methods to verify correctness, such 
as verifying that a circuit description, an algorithm, or a network or security 
protocol meets its specification. In this article, I will be concerned, instead, with 
the verification of mathematical theorems. To be sure, there is no sharp dis- 
tinction between verifying mathematical statements and verifying claims about 
hardware and software systems, since the latter are typically expressed in math- 
ematical terms. But ordinary mathematical theorems have a special character, 
and raise distinct issues and challenges. 

Specifically, I will focus on interactive theorem proving, which involves work- 
ing interactively with a proof assistant to provide enough information for the 
system to confirm that the theorem in question has, indeed, a formal proof. In 
fact, many systems actually construct a formal proof object, a complex piece 
of data that can be verified independently. Systems with substantial mathe- 
matical libraries include Coq [P (including the Ssrcflect extension [H]), HOL 
[24], HOL light t28j, Isabelle |37j, and Mizar (25j. In September 2004, assisted 
by some students at Carnegie Mellon, I verified a proof of the Hadamard/de 
la Vallee Poussin prime number theorem [3|, using the Isabelle proof assistant. 
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Since then number of nontrival theorems have been formahzed, including the 
four-color theorem [18] , the prime number theorem O [30] , the Jordan curve the- 
orem Godel's first incompleteness theorem [321 [35], Dirichlet's theorem 
on primes in an arithmetic progression |29| . the Cartan fixed-point theorems 
[S], and various theorems of measure theory [211 [3S]. There are, moreover, 
some interesting large-scale verification projects underway. Thomas Hales is 
heading the Flyspeck project [27], which aims to verify a number of results in 
discrete geometry, including the Kepler conjecture. Georges Gonthier is head- 
ing the Mathematical Components project [171 119] . which aims to verify the 
Feit-Thompson theorem. Fields medalist Vladimir Voevodsky has launched a 
project to develop "univalent foundations" for algebraic topology, providing the 
basis for formal verification in a theorem prover like Coq. 

Checking the details of a mathematical proof is by no means the most inter- 
esting or important part of mathematics, and formal verification is not meant 
to serve as a substitute for mathematical creativity and understanding. But it 
is generally recognized that the mathematical literature is filled with misstate- 
ments, gaps, ambiguities, overlooked cases, omitted hypotheses, and so on, and 
that the lack of reliability is problematic [36]. Moreover, an increasing number of 
proofs today rely on extensive calculation, and there are currently no standards 
to ensure that mathematical software is sound. Mathematicians always strive 
for correctness, and formal verification is simply a technology that is designed 
to support that goal. 

Despite the achievements to date, however, formal verification is still not 
"ready for prime time." There is a steep learning curve to working with an 
interactive theorem prover, and verifying even straightforward mathematical 
results can be frustrating and time consuming. We need better libraries, au- 
tomated methods, and infrastructure to support verification efforts. This is an 
exciting time for a young and rapidly evolving field. 

In this article, I will focus on one small aspect of formal verification, namely, 
type inference. In the mathematical setting, the challenge of type inference, 
roughly speaking, is to keep track of the kinds of objects that appear in a 
mathematical statement and put that information to good use. What is common 
to the previous examples is that in each case the relevant information can be 
inferred from context: 

• In the expression "a is in G," the object of the word "in" is expected to 
be a set. 

• In "a6," multiplication takes place in the group that a and b are assumed 
to be an element of. 

• In "a;*/*!," one expects the arguments to be elements of a common struc- 
ture, for which a division operation is defined. 

Type inference thus involves not only inferring type information, but also infer- 
ring data and facts from type considerations. Of course, type inference is central 
to the theory of programming languages [39] , and many of the ideas and meth- 
ods that have been developed there have been transferred to the mathematical 
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setting. But, as will become clear, mathematical type inference has a distinct 
flavor. Here I will focus primarily on the approach to type inference used in the 
Mathematical Components project, which relies on a proof language, Ssreflect, 
and the Coq theorem prover. 

In Section[21 1 will consider what is desired from a mathematical perspective. 
In Section [31 I will discuss some of the underlying axiomatic frameworks, and 
dependent type theory in particular. In Section |4l I will describe some of the 
mechanisms in Coq that are designed to meet the challenges posed in Section [51 
In Section [5l I will describe the way some of these mechanisms are used in the 
Mathematical Components library, and in Section [51 I will briefly indicate some 
alternative approaches. 

2 Mathematical type inference 

One hallmark of modern mathematics is the tendency to identify mathematical 
objects as elements of algebraically characterized structures. Such structures, 
and classes of such structures, can be related in various ways: 

• Structures in one class may be viewed as elements of a broader one. For 
example, every abelian group is, more generally, a group, and every group 
is, more generally, a monoid. Sometimes the inclusions are obtained by 
taking reducts, which is to say, ignoring parts of the structure. For exam- 
ple, the additive part of a ring is an abelian group, while the multiplicative 
part is a monoid. 

• A particular structure or a structure in one class can often be embedded 
in a larger structure. For example, the integers can be embedded in the 
reals, and every integral domain can be embedded in its field of fractions. 

• Uniform constructions can be used to build elements of one class of struc- 
tures from elements of another. For example, the units in any ring form 
a group, under the associated multiplication; the set of automorphisms of 
a field (or those fixing some chosen subfield) form a group under compo- 
sition; any metric space gives rise to a topological space determined by 
the metric; the field of fractions of any integral domain is a field; and the 
quotient of a group by a normal subgroup is again a group. 

What makes this perspective useful is that it allows one to transfer insights and 
results gained from one domain to another, and apply background knowledge 
and expertise uniformly in different settings. The challenge for interactive proof 
assistants is to reap these benefits. 

There are various ways that algebraic methods promote efficiency: 

• They allow us to reuse notation. For example, one may wish to use the 
symbols and -|- with respect to the integers, the reals, and arbitrary 
rings. 
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• They allow us to reuse constructions. For example, summation X^ie/ '^i 
the integers, reals, and an arbitrary ring can be viewed as instances of the 
same construction, namely an iteration of the corresponding addition. In 
fact; various "big" operations, including multiplication, logical operations 
of conjunction and disjunction, lattice operations of meet and join, and so 
on can be viewed as iterations of an associative operation in an arbitrary 
monoid. 

• They allow us to rouse facts. Various identities involving big operations 
can be viewed as instances of general laws that can be instantiated in 
the different settings. For example, some identities involving summations 
presuppose that the addition is commutative. Other identities hold in the 
presence of a multiplication that distributes over addition. We implic- 
itly recognize that such facts hold at various degrees of generality, and 
instantiate them as appropriate. 

Any proof assistant that is designed to formalize contemporary mathematical 
arguments should support these types of reuse. 

In the theory of programming languages, type inference allows users to omit 
information that can be inferred from context. For example, if we write f{i) 
and i is known to range over the integers, we can infer that / is a function from 
the integers to some other domain. Various kinds of "polymorphism" allow one 
to reuse symbols and code across different domains. In the context of formally 
verified mathematics, there are really two types of information that can be 
inferred: 

• data: for example, the appropriate multiplication in an expression a-b, or 
the appropriate summation operation in an expression J2ieA /(*)• 

• facts: for example, the fact that (a • 6) • c is equal to a ■ (6 • c), when the 
multiplication in the relevant structure is associative. 

In the ncixt sc;(;tion. wc will see that in certain formulations of logic, these two can 
be understood as instances of a common phenomena. In other words, inferring 
a fact can be viewed as inferring a special kind of data, namely "evidence" or 
"the fact" that the associated claim is true. 

To summarize, in interactive theorem proving, type inference may be invoked 
when the system parses an expression, but also when the user applies a lemma, 
or searches for a lemma to apply. The goal of type inference is to allow the 
user to omit information systematically when such information can be inferred 
from context. Not only does this save time and energy and reduce tedium, but 
it also ensures that the expressions we type look like the mathematics we are 
familiar with, lending support to the claim that our formalizations adequately 
"capture" informal mathematical practice. 
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3 Dependent type theory 



In order to verify mathematical proofs in a given domain, one has to first choose 
a formal axiomatic framework that is flexible enough to model arguments in that 
domain. Experience from the last century has shown that the Zermelo-Fraenkel 
axioms of set theory provides a remarkably robust foundation for mathematics. 
Indeed, the Mizar system [251 , which has perhaps the most extensive mathe- 
matical library, is based on an extension of ZF known as Tarski-Groethendieck 
set theory. 

But, in set theory, every object is a set, meaning that the axiomatic frame- 
work does not distinguish between numbers, functions, structures, and other 
objects. For the purposes of type inference, it is often useful to have such dis- 
tinctions built into the underlying formal system. A number of proof assistants 
today, including HOL [24 , HOL light [28j, and Isabelle [37], are based on for- 
mulations of higher-order logic like Church's simple type theory [8] . One starts 
with basic types, such as a type nat of natural numbers and a type bool of 
boolean truth values, and adds constructors for forming new types. The most 
important of these are function types: whenever A and B are types, so is A — > B, 
intended to denote the type of functions from A to B. One can also allow, for 
example, product types A x B, denoting the type of ordered pairs from A and 
B. Most proof systems have additional mechanisms to support the definition 
of common mathematical data types and structures, and allow "polymorphic" 
variables ranging over types. 

The problem with simple type theory, however, is that it is too simple, since 
ordinary mathematical structures often depend on parameters. For example, 
for each n, R" is a vector space, and for every n > 1, the integers modulo n 
form a ring. Thus one may wish to have types 

• list A n, denoting sequences of objects of type A, with length n; and 

• Zmod n, denoting the ring of integers modulo n. 

In dependent type theory^ types can depend on parameters in this way. Notice 
that such a move tends to blur the distinction between types and terms. For 
example, in list A n, the first argument is supposed to denote a type, whereas 
the second argument is supposed to be a term of type nat. In some presentations 
of type theory, this is achieved by having special types, called universes, whose 
terms are also construed as types (see, for example, the presentation of Martin- 
Lof type theory in [471 Section 7.1]). Contemporary presentations more often 
take types to be inhabitants of a third level of syntactic objects, known as 
"sorts" or "kinds" (see The specific details need not concern us here; only 
the fact that terms as well as types can depend on parameters that are again 
terms or types. 

In dependent type theory, the type A — B of functions which take an argu- 
ment in A and return a value in B can be generalized to a dependent product 
]^^.^B(x), where B(x) is a type that can depend on x. Intuitively, elements of 
this type are functions that map an element a of A to an element of B(a) . When 
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B does not depend on x, the result is just A — B. Similarly, product types A x B 
can be generalized to dependent sums X^x a^^-'^^- Intuitively, elements of this 
type are pairs (a, b) , where a is an element of A and b is an element of B(a) . 
When B does not depend on x, this is just A x B. 

In the next section, we will consider one particular theorem prover, Coq. 
Coq's underlying logic is a dependent type theory known as the calculus of 
inductive constructions, or CIC |12j , which extends the original calculus of con- 
structions due to Coquand and Huet [TT] . The calculus of inductive construc- 
tions has four distinguishing features: 

• It is a powerful and expressive dependent type theory. 

• It incorporates the "propositions as types" correspondence. 

• It is constructive, in that every expression in the system has a computa- 
tional interpretation. 

• The computational interpretation of terms is used in type checking. 

• Type checking is decidable. 

These features are not to everyone's taste, and we will see in Section [5] that 
other proof assistants can reject any or all of them. I will elaborate on each, in 
turn. 

One striking feature of the Calculus of Inductive Constructions is that there 
are only two basic type-forming operations: dependent products and inductive 
types. We have already discussed dependent products. Inductive types allow one 
to define structures that can be characterized as the closure of a set under some 
basic operations, like the natural numbers, or lists and trees over a type. But, 
in the CIC, the construction is general enough to include dependent sums, as 
well as to interpret basic logical notions, like conjunction, disjunction, universal 
and existential quantification, and equality. In fact, the system has the logical 
strength of strong systems of set theory . 

In order to interpret logical operations in terms of type-theoretic construc- 
tions, the CIC relies on what has come to be known as the Curry-Howard 
"propositions as types" correspondence. The point is that logical operations 
look a lot like operations on datatypes. For example, in propositional logic, 
from A and B one can conclude A A B. One can read this as saying that given a 
proof a of A and a proof b of B of _B one can "pair" them to obtain a proof (a, 
b) of A A B; or given the "fact" a that A holds, and the fact b that B holds, one 
obtains the fact (a, b) that A A B holds. Moreover, from the fact that A A B 
holds, one can extract the fact that A holds, and, similarly, B. If you replace 
A A B by A X B, this is nothing more than a characterization of the product type. 
In other words, if we posit a new collection Prop of types and take the product 
constructor to map elements A : Prop and B : Prop to A x B : Prop, the rules 
governing products for elements of Prop are exactly the desired logical rules for 
conjunction. 
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Under this correspondence, implications A — B are just instances of function 
types, and bounded universal quantifiers Vx : A. B(x) are just instances of the 
dependent product construction. In other words, a proof of Vx : A. B(x) can 
be viewed as a procedure which, given any object a : A returns a proof of 
B(a). This explains Coq's notation forall x : A, B x for dependent prod- 
ucts. Similarly, the logical construction 3x : A. B(x) is just an instance of the 
dependent sum. Using inductively defined types, given any type A one can form 
IaCxjY) : Prop which, intuitively, denotes the proposition that x is equal to y 
as elements of A. 

One can take the propositions-as-types as expressing a deep insight into the 
nature and meaning of logical operations [SUSS]- But one can just as well view 
it as a notational convenience which, moreover, allows a proof assistant to treat 
logical and mathematical operations uniformly. For example, one can take the 
transitivity of inequality on the natural numbers, leq_trans, to be a term of 
type 

Vx : nat , y : nat , z : nat ,x<y— >y<z— >x<z. 

This last expression, in turn, it a term of type Prop. One can view leq_trans 
not just as the fact that less-than-or-equal is transitive, but also as a function 
which, given elements x, y, and z in the natural numbers as well as the facts that 
X < y and y < z, return the fact that x < z. Thus, given a : nat, b : nat, 
and c : nat, the term leq_trans a b c denotes the implication a < b — 
b < c — > a < c. Moreover, we can express that H is the fact that a < b by 
writing H : a < b, in which case leq_trans a b c H denotes the implication 
b < c — >^ a < c. 

The propositions-as-types correspondence is particularly popular as a foun- 
dation for constructive mathematics, where assertions are expected to have di- 
rect computational significance. Every term in Coq can be viewed as a compu- 
tational object, subject to evaluation. For example, if ttq and tti denote the two 
projections from a product type A x B, the a term TTgCa, b) can be "reduced" 
or "evaluated" to a. In fact, every term in Coq can, at least in principle, be 
reduced to a canonical normal form. In particular, if t is a closed term of type 
nat, then t reduces to a numeral. Coq, moreover, makes use of this computa- 
tional interpretation when checking types. For example. If C(x) is a type that 
depends on a value x of type A, the system can recognize that CCvroCa, b)) is 
the same type as C(a). 

The decidability of type checking amounts to the fact that given a term, 
t, and a type, T, the type-checker can, deterministically, decide whether or 
not t has type T. This is clearly a useful property to have, though we will 
see, in Section [6l that it imposes strong restrictions. Under the propositions- 
as-types correspondence, the decidability of type checking takes on additional 
significance. Suppose P is a term of type Prop, expressing, for example, Fermat's 
last theorem. Then a term t of type P is a proof that P is true. Proving Fermat's 
last theorem thus amounts to constructing a term of type P, and the decidability 
of type checking implies that such a term can be recognized, algorithmically, as 
a valid proof. 
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4 Type inference in Coq 



Now that we have a sense of Coq's axiomatic framework, let us explore some of 
the mechanisms the system offers to address the challenges raised in Section [2j 
Generally speaking, type inference is triggered when the system is called on 
to determine the type of a term, or to check that a term has an appropriate 
type, when some information has been left implicit. But because dependent 
types depend on the values of their parameters, inferring a type can entail 
inferring such values. Recall that in Section [2] we distinguished between two 
types of information that can be inferred, namely, data and facts. With the 
propositions-as-types correspondence in place, inferring a fact — such as the fact 
that multiplication is associative — is a matter of inferring a value of a type 
P, which is in turn of type Prop, where P expresses the expected associativity 
property. 

We will consider three principal mechanisms. Implicit arguments allow users 
to systematically leave information out of an expression when this information 
can be inferred from context. Coercions allow users to cast, implicitly, objects 
of one type to objects of another. Finally, canonical structures let the user 
register certain objects as components of a larger structure, providing useful 
information to the type inference process^ 

It will be helpful to illustrate these with a running example. The following 
definition declares a new type, group: 

Record group : Type := Group 
{ 

carrier : Type; 

mulg : carrier -> carrier -> carrier; 

oneg : carrier; 

invg : carrier -> carrier; 

mulgA : forall x y z : carrier, 

mulg X (mulg y z) = mulg (mulg x y) z; 

}. 

According to this type declaration, group is a record type, consisting of a carrier, 
a multiplication, an identity, and an inverse. These are assumed to satisfy the 
requisite axioms, such as the associativity of multiplication. If G has type group, 
that is, G : group, then the components of G are carrier G, mulg G, oneg G, 
and so on. Conversely, given elements my_carrier, my_mul, my_one and so on 
of the right type, the term Group my_carrier my_mul my_one . . . denotes the 
corresponding group. 



^For more detail than is provided below, see Coq's online reference manual. All three 
mechanisms were initially introduced to Coq by Amokrane Saibi |32l 1401 141) , who credits the 
idea of using implicit arguments in the theorem proving context to Peter Aczel. Implicit ar- 
guments were further extended by Hugo Herbelin and Matthieu Sozeau. Canonical structures 
received little attention until they were revived and used aggressively by Gonthier; see, for 
example, 1171 . 
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Notice that wc arc relying on dependent type theory here. The type group is 
a classic example of a dependent sum, since, for example, the type of the second 
component, carrier -> carrier -> carrier, depends on the value carrier 
of the first component. The arguments of the corresponding projections bear 
the associated dependences. For example, the term mulg, which picks out the 
the second component, has type forall G : group, carrier G -> carrier 
G -> carrier G, a dependent product. 

Notice also that the proposition-as-types correspondence is being put to good 
use. For example, the type of the fifth component, mulgA, is the proposition 
that mulg is associative. Assuming G : group, the term mulgA G has type 

forall X y z : carrier G, 

mulg G x (mulg G y z) = mulg G (mulg G x y) z 

which is itself a term of type Prop. Thus mulgA G denotes the fact that mul- 
tiplication in mulg G is associative, a fact that can be applied to elements of 
the carrier of G just as in the example of leq_trajis above. In this way, the 
propositions-as-types correspondence provides a natural and convenient way to 
think of the group structure as including not only the relevant data — the carrier 
of the group and group operations but also the relevant properties. 

In a context where we have G : group, g : carrier G, and h : carrier 
G, the term mulg G g h represents the product of g and h under the multi- 
plication operation of G. The implicit argiiments mechanism in Coq allows us 
to write mulg _ g h, replacing the first argument by an underscore. Doing so 
means that we expect the type inference algorithm to infer the value of that 
argument from context, by finding a solution to the constraints imposed by the 
fact that the resulting term should be well typed. The algorithm proceeds by 
instantiating the first element with a variable, ?. The term mulg ? then has 
type carrier ? -> carrier ? -> carrier ?. Since this term is applied to 
g : carrier G, to get the types to work out the system has to solve a simple 
unification problem, namely, instantiating ? to unify carrier ? with carrier 
G. Thus ? is instantiated to G, and the algorithm has inferred the relevant 
parameter. With this in mind, one can introduce a new notation: 

Notation "g * h" := (mulg _ g h) . 

This enables one to write g * h for multiplication in any group, allowing the 
group in question to be inferred from the type of g. 

In this example, the implicit argument mechanism was used to infer a pa- 
rameter in the application of a function, mulg. But the mechanism can be used 
just as well to infer parameters during the application of a lemma. For example, 
recall the transitivity lemma leq_trans from the last section. This takes five 
arguments — three natural numbers, x, y, z, and the facts x < y and y < z — and 
returns the fact x < z. Suppose we declare the first three arguments to be 
implicit. Then given HI : a < b and H2 : b < c, the term leq_trans HI H2 
has type a < c. Moreover, when we are building a proof interactively in Coq, if 
we apply leq_traiis HI to a subgoal a < c, type inference similarly infers the 
missing arguments and leaves the us with the goal b < c. 
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Coercions are commonly used in programming languages, for example, when 
adding a real and an integer triggers the coercion of the integer to a real. In 
the context of mathematical theorem proving, coercions have other uses as well. 
In our running example, one would ordinarily write g : carrier G to specify 
that g is an element of the carrier of G. Writing g : G instead yields an error, 
because the system expects something of type Type on the right side of the 
colon, and G has type group. But declaring 

Coercion carrier : group >-> Type. 

informs Coq that the function carrier can always be used to coerce a group to 
a type. If one then enters g : G, the algorithm finds itself facing a group on the 
right side of the colon but expecting a type, and readily inserts the coercion. 

The last feature that we will discuss, canonical structures, provides an inverse 
to coercion, of sorts. In the example above, we used the carrier function to 
coerce a record structure to one of its projections. Canonical structures makes 
it possible for the type inference algorithm to pass in the other direction, and 
recognize a particular object as the projection of a larger structure. To illustrate, 
suppose we define 

IntGroup := Group int addi zeroi negi addiA ... 

thereby declaring the integers with addition to be an instance of a group. Some- 
what perversely, this will allow us to write mulg IntGroup i j instead of i + 
j, when we have i j : int. Less perversely, this will allow us to apply general 
theorems about groups to this particular instance. But what happens now when 
we write i * j ? This expression is shorthand for mulg _ i j . After instanti- 
ating the first argument to a variable, ?, the type inference algorithm is faced 
with the imification problem carrier ? = int, and gets stuck. Declaring 

Ccinonical Structure IntGroup. 

registers the fact carrier IntGroup = int with the system for use in type 
inference. One can view this as a "hint" to the unification process [2]. Now 
when the type inference algorithm gets stuck as above, it can appeal to a table 
of such hints, and use the relevant one to recognize that the integers can be 
viewed as the carrier of the IntGroup structure. The algorithm then replaces 
int by carrier IntGroup and solves the unification problem. 

The mechanisms just described are not exceedingly complicated, but we will 
see in the next section that they are remarkably robust with respect to the 
challenges posed in Section [5] Canonical structures can, moreover, be used in 
clever ways to trick the type inference algorithm into carrying out various kinds 
of useful automation 23^ . 

To summarize, type checking is triggered when the user enters an expression 
or applies a lemma, possibly leaving some arguments and facts implicit. Coq's 
type inference engine has four resources at its disposal to fill in the remaining 
information: 

1. unification can be used to infer implicit arguments; 
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2. coercions can be inserted to resolve a type mismatch; 

3. the unification algorithm can refer to a database of unification hints to 
solve unification problems involving a projection of a canonical structure; 
and 

4. when all else fails, the algorithm can simplify terms or unfold definitions 
according to the CIC's computational interpretation of terms, and then 
retry the previous steps. 

Generally speaking, implicit arguments can trigger arbitrary instances of higher- 
order unification, which is known to be undecidable ,14,. So, at best, type in- 
ference can only aim to search a reasonable fragment of the space of possible 
instantiations for an implicit argument. And even within decidable fragments, 
unpacking definitions and unfolding terms can easily lead to combinatorial ex- 
plosion. Nonetheless, Coq's type inference algorithm consists, essentially, of 
iterating the steps above, relying on heuristics to limit the possibilities in the 
fourth step. 

5 The mathematical components Hbrary 

This section provides a brief indication of some of the ways that the mechanisms 
for type inference discussed in Section H] have been used towards Gonthier's for- 
malization of the Feit-Thompson theorem [TS] , which asserts that finite groups 
of odd order are solvable. These examples only scratch the surface; for more 
detail, see [HI [H [211 [22] . 

Recall that Coq's logic is constructive. In contrast, many principles and 
methods that are commonly used in contemporary mathematics are not con- 
structively valid. For example, constructively, one cannot assume the law of 
the excluded middle, or prove the existence of an x satisfying a property P by 
assuming there is no such x and deriving a contradiction. Extensionality fails: 
one cannot, in general, prove that two functions / and g from A to B are equal 
by proving that f{x) = g{x) for every x. Choice fails as well: even if one has 
proved that for every x va A there is a y in _B such that some property holds, 
one cannot assume that there is a function / that picks out such a y for every 

X. 

On the other hand, these properties generally hold in finite domains. Since 
the Feit-Thompson theorem is an extended exploration of properties of finite 
groups, one would like to take advantage of these features when they are avail- 
able. Thus, in the Ssrefiect library, there are general structures for types with 
a decidable equality relation (that is, ones where the relation can be computed 
by a function returning a boolean value of "true" or "false," ensuring that it 
satisfies the law of the excluded middle); finite structures; and structures that 
can be equipped with choice functions. For example, one can define a structure 
for types with decidable equality as follows: 

Record eqType : Type := EqType 
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{ 

carrier : Type; 

rel : carrier -> carrier -> bool; 
ax : forall x y, (x = y) = (rel x y) 

}. 

In the last line of the record, the expression rel x y of type bool is coerced 
to the proposition that the value of this expression is equal to true. In other 
words, ax is the proposition that rel x y holds if and only if x = y. Declaring 
carrier to be a coercion allows one to write x : T whenever we have T : 
eqType. Implicit arguments allow one to use the notation x == y in place of 
rel T X y whenever x and y are elements of the carrier of such a T. Finally, 
canonical structures allow one to associate the relevant boolean equality relation 
with the natural numbers, so that one can write x == y when we have x y : 
nat, as well. (This is a slight simplification of the implementation in the Ssreflect 
library [TT].) 

Section [5] noted that "big operations" such as^, Y[, C\, [J, A; V can all be 
viewed as instances of iterations of an associative binary operation. But such 
operations come in many different flavors: one can sum over a list, a numeric 
range, or a finite set, and these summations will satisfy different properties 
depending on whether the underlying structure is a semigroup, an abelian semi- 
group, or a ring. Ssreflect comes with an overarching "bigop" library, and once 
again type inference plays a key role in making it work [6_, . 

Type inference is also used to manage algebraic class inclusions (between 
rings, commutative rings, fields, and son on) and algebraic constructions: for 
example, the set of n by n matrices over a ring forms a ring when n > 0, and 
the set of polynomials over a commutative ring again forms a commutative ring. 
Type inference ensures that the relevant algebraic facts are readily available, 
and allows a uniform use of notation [T71 [^U] . Definitions in the Ssrefiect library 
have been carefully chosen so that if G and H are groups of the same type (more 
precisely, subgroups of some ambient group type), then the quotient notation 
G / H makes sense; but when H is in fact a normal subgroup of G, as in the 
usual construction of a quotient group, G / H is a group with all the expected 
properties [22] ■ For another example, when a group G happens to be abelian, it 
is often treated as a Z-module and written additively. So, for example, one can 
write g *+ n for scalar multiplication of g by n whenver g is an element of the 
group and n is a natural number. Type inference is used to mediate between 
these two "views" of an abelian group. 

Type inference also helps with mundane mathematical conventions. For 
example. Section [5] noted the conflation of groups with sets. If G and H are 
subgroups of an ambient finite group, and A is a subset of that group, then 
G n H and C_G(A) (the centrahzer of A in G) are both groups. But they are also 
just sets with the ambient group operation; an element x is in G H H if and only 
if it is in G and H, and x is in C_G(A) if and only if x is in G and commutes 
with every element of A. Type inference mediates between these two views of a 
construction — that is, of yielding both a group and a set — allowing one to apply 
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lemmas involving groups in some instances and lemmas involving sets in others. 
For another example, a homomorphism between groups G and H is a function 
between G and H equipped (using a record type) with additional properties. 
Coercion allows one to use ordinary function notation with morphisms, such as 
f X and fog. In the other direction, canonical structures automatically infer 
the fact that f o g is a homomorphism when f and g are, giving f o g a similarly 
dual status as function and morphism. 

Canonical structures can even be used to make sense of mildly abusive math- 
ematical notation. For example, if U and W are subspaces of a vector space V, 
it is common to write U + W for set {u + w\ u€U,'w€ W}. Mathematicians 
will often say "J7 + is a direct sum" when U and W have trivial intersection, 
ignoring the fact that this is a property of the pair {U, W) which is impossible 
to read off from the U + W alone. Gonthier has shown, however, that canonical 
structures provide a convenient way of supporting this abuse of language [20] . 

6 Limitations and other approaches 

The mechanisms supporting type inference that were described in Section [4] are 
not the only ones available in Coq. In particular, Coq now has a "type class" 
mechanism [44] . Type classes and canonical structures serve similar purposes, 
but whereas canonical structures are handled within the type inference loop 
described at the end of Section 21 the type class mechanism collects constraints 
that are passed to a separate inference engine at the end of the process. Spitters 
and van der Weegen |45j have experimented with type classes in the context of 
mathematical type inference, with positive results. 

But one may wish to stray even further from Coq's mindset. Recall some of 
the key features of that proof assistant: 

• An elaborate type theory is built in to the underlying axiomatic frame- 
work. 

• Using the propositions-as-types correspondence, data and facts are han- 
dled in the same way, so theorems can be applied to arguments and hy- 
potheses just as functions are applied to arguments. 

• The underlying logic is constructive, and every term has computational 
significance. 

• Type checking makes use of the computational interpretation of terms. 

• Type checking is decidable. 

These are very strong constraints, which interact with each other in subtle ways 
and place strong restrictions on the way mathematics is represented and carried 
out. Not every proof assistant adopts such a framework. In fact, most reject 
the third, allowing classical reasoning that is ubiquitous in contemporary math- 
ematics. Similarly, the propositions-as-types correspondence is usually linked 
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to constructive theories, though there is no reason that it cannot be adopted in 
classical frameworks as well. 

Although the mechanisms for type inference described in this article scale 
reasonably well, their use in real mathematical settings can be complex and 
delicate. Moreover, when an expression fails to typecheck, error messages from 
the system are often uninformative, and it can be frustrating and difficult to 
diagnose the problem. There are, moreover, rigid limitations to dependent type 
theory that stem from the commitment to keep type checking decidable. This 
is so because type checking algorithms are constrained to focus on syntactic 
structure, without incorporating background knowledge. For example, if list 
A n denotes the type of vectors of elements of A of length n, and we have t : 
list A (0 + n) , then, in Coq, t also typechecks as an element of list A n. 
In other words, Coq recognizes these two types as being the same. But entering 
t : list A (n + 0) yields a type error; Coq refuses to recognize that list A 
(n + 0) is the same as list A n. What is going on is that addition in Coq is 
defined by recursion on the first argument, so that the the term + n reduces 
to n under the computational interpretation. But the fact that n + is equal 
to is a mathematical fact, and there is no general way to incorporate arbitrary 
mathematical information in type checking while maintaining decidability. 

Still, some have explored ways of making type judgments more flexible while 
maintaining decidability [TJ [71 35] . An alternative is to give up the decidability 
of type checking, and accept the fact that some type judgments will require proof 
from the user. This is the path chosen by NuPrl [10] and PVS (43j. Yet another 
alternative is to jettison type theory altogether, and move to an axiomatic sys- 
tem like set theory, which offers maximum flexibility while relinquishing all the 
benefits of types; and then try to recapture some of those benefits by adding 
an extra layer of automation to register and manage domain information out- 
side the axiomatic theory. Such "soft typing" mechanisms can be found, for 
example, in Mizar [25j . 




This article has focused on the modeling of mathematical language from the 
point of view of contemporary interactive theorem provers. Others [T31[H] have 
come at the problem from the perspective of natural language processing. In 
the long run, it seems likely that the various approaches will converge. 

Inferring domain information is essential to modeling mathematical language 
and reasoning. Gonthier's work on the Feit-Thompson theorem shows that it is 
possible to model full-blown algebraic reasoning in an interactive proof systems. 
But other approaches should also be explored, and continued experimentation 
and innovation is needed to develop better support for verifying ordinary math- 
ematical proofs. 
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